Aspects of the present disclosure may relate to reducing the effects of transmission failures when transmitting content such as video in an environment such as Dynamic Adaptive Streaming over HTTP (DASH) over File Delivery over Unidirectional Transport (FLUTE) environment.
Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks are generally multiple-access networks capable of supporting multiple users by sharing the available network resources.
A wireless communication network may include a number of base stations that can support communication for a number of user equipments also referred to as mobile entities. A user equipment may communicate with a base station via a downlink and an uplink. The downlink (or forward link) refers to the communication link from the base station to the user equipment, and the uplink (or reverse link) refers to the communication link from the user equipment to the base station.
The third Generation Partnership Project (3GPP) Long Term Evolution (LTE) represents a major advance in cellular technology as an evolution of Global System for Mobile communications (GSM) and Universal Mobile Telecommunications System (UMTS). The LTE physical layer (PHY) provides a highly efficient way to convey both data and control information between base stations and mobile entities. In prior applications, a method for facilitating high bandwidth communication for multimedia has been single frequency network (SFN) operation. SFNs utilize radio transmitters, such as, for example, those in base stations, to communicate with subscriber equipments. In unicast operation, each base station is controlled so as to transmit signals carrying information directed to one or more particular subscriber equipment.
In broadcast operation, several base stations in a broadcast area may broadcast signals in a synchronized fashion, carrying information that can be received and accessed by any subscriber equipment in the broadcast area. The generality of broadcast operation enables greater efficiency than unicast service in transmitting information of general public interest, for example, event-related multimedia broadcasts. As the demand and system capability for event-related multimedia and other broadcast services has increased, system operators have shown increasing interest in making use of broadcast operation in 3GPP networks.
Transmission of content, such as video content, may be performed by various methods in communication networks. In the case of video content, for example, transmission of video information from a video source to a display can be made via unicast transmissions or multicast/broadcast transmissions. Unicast transmissions are directed to a specifically targeted receiving device. To obtain a unicast transmission, a target device may have a Uniform Resource Locator (URL) with the address of the video source, and may generate an HTTP GET command that it may send to the video source (typically a server) to facilitate download of the video file.
A known method for transmission of video in a unicast environment is through Dynamic Adaptive Streaming over HTTP (DASH). Use of DASH in unicast obtains the entire file. DASH may convert the video file into smaller components called DASH segments, which may be reassembled at the receiving device to display the desired video.
Multicast or broadcast transmissions, such as in Evolved-Multimedia Broadcast/Multicast Service (eMBMS), present different considerations, as the transmissions are sent to multiple receiving devices. In these environments, the receiving devices can obtain information before the associated system actually takes steps to obtain that information. The receiving device may store that received information in a local cache. When the system (typically at the application layer) generates a URL to obtain the information, the generated URL may point to content already in the local cache rather than at the server side as in the unicast environment.
DASH in combination with File Delivery over Unidirectional Transport (FLUTE) may be used in multicast environments. According to such a combination, video content may be converted into DASH segments and small groups of DASH segments may be accumulated by a FLUTE package engine (FPE), which in turn may convert the DASH segments into FLUTE packets for transmission. The structure of the DASH segments conforms to the ISO Base Media File Format (ISOBMFF). According to ISOBMFF, a segment is divided into boxes. A movie fragment comprises at least one header box called “moof” for “movie fragment”, associated with a data box called “mdat” for “movie data”, the box moof specifying the structure of the box mdat.
DASH, and most ISOBMFF-based adaptive streaming technologies, usually assumes an error-free transport layer. However, deployments such as eMBMS may rely on multicast User Datagram Protocol (UDP) or other broadcast data link layers such as DVB-GSE (Digital Video Broadcasting-Generic Stream Encapsulation) for the delivery of DASH segments. Although error correction coding techniques such as FEC (Forward Error Correction) are heavily used in these environments, loosing a complete packet is not dealt with by a eMBMS/FLUTE/DVB receiver.
In the worst case, when a loss is detected, the corrupted DASH segment is considered lost, and the DASH session will have a long playback interruption. However a DASH session based on the protocol MPEG-2 Transport Stream (TS) would not suffer such a loss, as TS is designed for lossy environments, i.e. loosing a few TS packets will not corrupt the whole segment. In the case of a DASH session based on ISOBMFF format, when the loss is only located in a data part (box mdat) of a segment, only a few samples (or even few blocks of a video slice) are lost, and the rest of the segment is usable. In contrast, when the lost is located in a header part (box moof), the end of the segment following the corrupted box moof is not usable. If the receiving device is coupled to a segment reader and thus does not process the DASH segment, loss information has to be communicated to the segment reader. Such losses could be handled by the receiving device.
However a receiving device based on MSE (Media Source Extension), JavaScript and HTML5 will very likely not know anything about the underlying delivery protocol, whether HTTP broadband or FLUTE. In addition, the receiving device could be a different device than the media player, for example a DASH eMBMS connected to a Wifi relay. In both cases, it may not be desirable for the receiving device to handle reformatting of a corrupted segment, for complexity reasons. Moreover, reformatting a corrupted segment would make further repair of the segment by a third-party device not possible, since it would not be aware of the loss.
Additionally, there are cases where the corrupted data are located within a header box moof, which makes the box, and consequently the remainder (box mdat) of the movie fragment, unusable. However, if the segment is not made of a single fragment (single moof box associated with a signlemdat box), but of several fragments each comprising a moof box and an associated mdat box, some other fragments could be intact after the corrupted box moof. In case the size data in the corrupted box moof is corrupted, all the fragments (boxes moof and mdat) following the corrupted box moof are lost since the positions in the segment of the boxes moof cannot be determined.
Thus it is desirable to handle partially corrupted fragments. It is further desirable to handle the case of a segment composed of multiple fragments with one fragment partially or totally corrupted, so as to enable processing of non-corrupted fragments following a corrupted fragment within a segment. It is also desirable to respect existing DASH deployments, and thus to ensure a backward compatibility so as to avoid disturbing or render inoperative the function of the existing user equipment to handle corrupted or not corrupted segments.